Daniel J Wilson

LLM code de-cruftification

February 2026

Reducing LLM “cruft” after large refactors

One simple strategy that’s worked well for me is a reviewer → verifier two-pass workflow.

Codebase
   ↓
Pass A: Reviewer → produces checklist only
   ↓
Pass B: Verifier → applies fixes + runs checks
   ↓
Clean repo

ExampleHere is an example of the prompt I am currently using (I will try to keep it updated). It is current as of 2026-02-05 14:25.

Use a reviewer + verifier paradigm to now go over all the code in [path].

Pass A (reviewer): Audit the refactor for dead code, duplicate paths, inconsistent patterns, and doc drift. Produce a checklist of fixes.
Pass B (verifier): Apply fixes, run lint/format/tests/build, and update impacted READMEs. Report deletions and results.

Goals:
- Remove all obsolete/duplicate code created by the refactor.
- Reduce complexity and redundancy (no parallel implementations).
- Ensure repo consistency (naming, structure, patterns).
- Update all impacted docs/READMEs.

Notes:
- Prefer deletion over deprecation. If something is unused, remove it.
- No new abstractions unless they reduce duplication across ≥2 call sites.
- No TODOs unless they include owner + next action + condition.
- If you touch a public API, update examples and changelog notes.

Why this works

LLMs tend to add layers and leave residue during refactors. Separating analysis from execution forces:

• less speculative code
• fewer unnecessary abstractions
• more aggressive deletion
• tighter repo consistency
• docs that actually match reality

Net effect: smaller diffs, simpler code, and a repo that stays clean instead of slowly accreting AI sludge.